Add continuous deployment workflow for PyPI publication #34
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's a PR with a Continuous Deployment workflow that should automatically build packages and push them to PyPI every time a GitHub release is made, as described in #33.
Besides the workflow, this requires some set-up to get PyPI and GitHub to work together. This used to be done using a long-lived access token, which PyPI would generate and which you would then put into GitHub as a secret, but that's been succeeded by a new system called OpenID.
If I get it right, this has GitHub log in to PyPI using its own credentials, and then it hands PyPI a signed statement that it's running a particular workflow. PyPI verifies that it's really talking to GitHub and that the statement was signed by it, and then gives GitHub a temporary token, essentially a cookie. This is then used by the rest of the workflow to push the packages. As a result, there are no long-lived tokens that can be leaked. (Except for a certificate or a private key or something at GitHub, but that's easier to secure.) All this is built into the
pypa/gh-action-pypi-publish
action.There's a second security feature, which is the use of a GitHub environment. I'm not sure exactly what that adds if you're the only one with access to the repository, but it allows you to set rules on whether and when a workflow runs, which makes it harder for people with commit but not admin access to do something malicious. I've linked the documentation below and leave it to you to set this up in just the way you want.
There's a lot of documentation on all this, so I've dug through it and found the relevant parts and put together some instructions. Untested but after careful reading this should at least be pretty close to working.
Create an Actions environment on GitHub
Documentation
It should be named
pypi
as that's what the workflow refers to. You can set up rules as you like, perhaps mark yourself as a "Required reviewer" so that others with access to the repository cannot change e.g. setup.py and run it without your permission. No secrets are needed, because we're using OpenID.Set up PyPI
Documentation
This will let you "Add a new pending publisher", which we need to do because we don't have a project yet. This deviates slightly from the documentation linked above, which is for if you already have PyPI releases.
PyPI will now check that any request to publish will come from GitHub, and that GitHub claims to be running the specified workflow. And it will automatically create a
transiflow
project on the first release.Make a release
If you now make a release on GitHub, the workflow should run, building the packages (source and wheel) and publishing them on PyPI.
For subsequent releases, you'll want to update the version both in
setup.cfg
and indoc/conf.py
, there's no automation around that in this PR.